为什么Redis不直接使用C语言的字符串？ |
您所在的位置：网站首页 › redis 查询语句 › 为什么Redis不直接使用C语言的字符串？ |
为什么Redis不直接使用C语言的字符串？
众所周知Redis有以下几种常见的数据类型 String（字符串）、List（列表）、Set（集合）、Hash（哈希）、Sorted set（有序集合）、Stream（流）、Geo（地理空间索引）、Bitmap（位图）、HyperLogLog（基数统计）等。 我们最常用的就是String（字符串）类型，String类型既可以存储字符串，也可以存储数字，甚至可以直接进行数值运算。 redis> set key1 value1 OK redis> get key1 "value1" redis> set key 1 Ok redis> INCR key (integer) 2Redis是使用标准C语言编写的，而Redis String类型底层使用SDS（Simple Dynamic String 简单动态字符串），但是却没有使用C语言字符串使用，这到底是为什么呢？ Redis的优点是快、安全、节省内存，在设计Redis String实现的时候，也深刻的体现了Redis的这三个优点。 提到Redis字符串的优点，需要先看一下C语言字符串的缺点，毕竟没有对比就没有伤害。 1. C语言字符串实现原理C语言字符串是使用char数组存储，以'\0'作为字符串结束，比如字符串”Redis“在C语言中存储结构就是下面这样：  那么这种存储方式有什么缺点呢？ 1.1 不安全C语言字符串这种特殊规定，就导致无法存储特殊字符。如果某个字符串中间包含'\0'字符，读取字符串的时候就无法读取到完整字符，遇到'\0'就结束了，像下面这样，只能读取到前半部分“Red”。  如果存储到C语言的字符串，无法完整读取，肯定是不安全的，所以C语言无法存储包含特殊字符的字符串（例如二进制数据）。 1.2 查询性能较低如果想要获取字符串的长度，需要遍历整个字符串，时间复杂度是O(n)，查询效率较低。 1.3 存在缓存区溢出风险开发中最常用的功能是拼接字符串，每次拼接字符串的时候，都要提前进行扩容。如果忘记扩容了，就会出现缓存区溢出。 1.4 扩容性能较差扩容过程是非常耗时的，而且每次拼接字符串的时候都需要提交扩容。想象一下，如果使用HashMap的时候，每次put操作都需要进行扩容，性能将会差到什么程度。 由于C语言字符串有这么多缺点，而Redis又追求极致性能，所以只能自己实现一套，看一下Redis字符串底层是怎么实现的？ 2. SDS底层实现原理Redis3.0版本之前的底层结构是这样的： struct sdshdr { // 记录buf数组中已使用字节的数量 // 等于SDS所保存字符串的长度 int len; // 记录buf数组中未使用字节的数量 int free; // 字节数组，用于保存字符串 char buf[]; }; 而最新Redis7.0版本，sds底层结构是这样的，分成5个实现：  为什么会有5种实现呢？ 看一下每种实现的len和alloc的类型就明白了，sdshdr8里面的类型是uint8_t，sdshdr16里面的类型是uint16_t，sdshdr32里面的类型是uint32_t，sdshdr64里面的类型是uint64_t，用来存储不同长度的字符串。使用合适的类型，可以节约大量内存。 Redis自己实现的字符串解决了C语言字符串遇到的问题，并且有以下几个优点： 2.1 存储安全sds简化版的存储结构是这样的： struct sdshdr { // 已经使用的字节数量 int len; // char数组总字节数量 int alloc; // 字节数组，用于保存字符串 char buf[]; }; 可以看出，Redis的字符串并不是用'\0'表示结尾，而是使用len记录了字符串的长度。想要取出完整的字符串，只需要遍历len长度即可。 2.2 查询性能较高Redis的字符串使用len记录了字符串的长度，想要获取整个字符串的长度，无需遍历字符串，只需要查询len值即可，时间复杂度是O(1)。 Redis采用空间换时间的做法，增加了存储空间，加快了查询性能。 2.3 避免缓存区溢出Redis的字符串使用len记录了字符串的长度，使用alloc记录整个数组的长度，(alloc - len)表示未使用的空间长度。 如果新增的拼接字符串长度小于未使用空间，就不用扩容了。 2.4 扩容性能较好Redis字符串还实现空间预分配和惰性空间释放的优化策略，减少扩容次数。 简单理解就是拼接字符串导致扩容的时候会多增加一些空闲空间，缩短字符串的时候并不立即释放这些空闲空间。 我是「一灯架构」，如果本文对你有帮助，欢迎各位小伙伴点赞、评论和关注，感谢各位老铁，我们下期见推荐阅读：《我爱背八股系列》面试官竟然问我订单ID是怎么生成的？难道不是MySQL自增主键？ 面试官竟然问我怎么分库分表？幸亏我总结了一套八股文 面试官竟然问我怎么实现分布式锁？幸亏我总结了全套八股文 面试官竟然问我消息队列为啥会丢失消息？幸亏我总结了全套八股文 面试官问我MySQL索引为啥用B+树？我让他去问作者 记一次ThreadLocal引发的线上故障，年终奖没了，可能还面临辞退 一篇文章讲清楚MySQL的聚簇/联合/覆盖索引、回表、索引下推 面试官竟然问我MySQL事务的底层原理？幸亏我总结了全套八股文 MySQL的锁这么多，不知从何学起，看完这篇文章就够了 面试官问我一条update语句加了多少锁？我总结了全套八股文 记一次排查线上MySQL死锁过程，不能只会crud，还要知道加锁原理 彻底搞懂三大MySQL日志，Redo Log、Undo Log、Bin Log 高级程序员必知必会，一文详解MySQL主从同步原理 查询效率提升10倍！3种优化方案，帮你解决MySQL深分页问题 别再问我MySQL为啥没走索引？就这几种原因，全都告诉你 【干货】MySQL底层架构设计，你了解多少？ 学会使用MySQL的Explain执行计划，SQL性能调优从此不再困难 吐血总结十三条经验，帮你创建更合适的MySQL索引 精心整理16条MySQL使用规范，减少80%问题，推荐分享给团队 手把手教你定位线上MySQL慢查询问题，包教包会 我说MySQL联合索引遵循最左前缀匹配原则，面试官让我回去等通知 MySQL查询性能优化七种武器之索引潜水 手把手教你定位线上MySQL锁超时问题，包教包会 不知道怎么分析MySQL查询瓶颈，这款自带工具太香了，强烈推荐 MySQL查询性能优化七种武器之链路追踪 三道MySQL联合索引面试题，淘汰80%的面试者，你能答对几道 MySQL查询性能优化七种武器之索引下推 大家都在用MySQL count(*)统计总数，到底有什么问题？ 一灯架构：硬核解析MySQL的MVCC实现原理，面试官看了都直呼内行 一灯架构：线上服务宕机，码农试用期被毕业，原因竟是给MySQL加个字段 一灯架构：如何优雅的备份MySQL数据？看这篇文章就够了 一灯架构：我说HashMap初始容量是16，面试官让我回去等通知 一灯架构：不允许还有Java程序员不了解BlockingQueue阻塞队列的实现原理 一灯架构：Java程序员必会Synchronized底层原理剖析 一灯架构：再有人说synchronized是重量级锁，就把这篇文章扔给他看 一灯架构：硬核剖析ThreadLocal源码，面试官看了直呼内行 一灯架构：夯实Java基础，一篇文章全解析线程问题 一灯架构：死磕面试系列，Java到底是值传递还是引用传递？ 一灯架构：死磕Java面试系列：深拷贝与浅拷贝的实现原理 一灯架构：重大发现，AQS加锁机制竟然跟Synchronized有惊人的相似 一灯架构：硬核剖析AQS源码，深入理解底层架构设计 一灯架构：干货，深入剖析ReentrantLock源码，推荐收藏 一灯架构：还不懂Java线程池实现原理，看这一篇文章就够了 一灯架构：面试官不按套路，竟然问我Java线程池是怎么统计线程空闲时间？ 一灯架构：Java阻塞队列中的异类，SynchronousQueue底层实现原理剖析 |
【本文地址】
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |